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Introduction 


Dilbert’s  Cloud  Philosophy 

(c  2009  Scott  Adams) 


LETS  IMPLEMENT 
CLOUD  COMPUTING  SO 
I  HAVE  SOMETHING  TO 
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Demystifying  cloud,  what  cloud  is  and  is  not... 


Cloud  is... 

...on-demand 

Clouds  can  provide  an  almost  immediate  access  to  a  pool  of  hardware  resources  (compute,  network  and  storage) 
that  can  be  allocated  and  provisioned  on-demand 

...scalable  and 
elastic 

The  key  characteristic  of  a  cloud  service  is  the  ability  to  dynamically  provision  and  de-provision  compute,  memory, 
and  storage  resources,  and  to  be  able  to  seamlessly  scale  services  (up  or  down)  to  meet  client  needs 

...pay-as-you-use 

Vendor-provided  cloud  solutions  do  not  require  upfront  capital  investments  by  the  buyer.  Billing  is  tied  to  metered  use 
of  resources,  shifting  expenses  from  CapEx  to  OpEx.  Internally  or  externally  hosted  private  clouds  do  require  CapEx, 
but  have  the  potential  to  reduce  both  CapEx  and  OpEx 

Cloud  is  not... 

...simply 

virtualization 

While  many  cloud  solutions,  both  public  and  private,  leverage  virtualized  infrastructure  resources  to  deliver 
functionality,  cloud  raises  the  bar  by  providing  on-demand  provisioning.  Publicly-announced  private  clouds  are 
essentially  an  aggressive  virtualization  program  on  top  of  the  traditional  enterprise  IT  stack 

...just  applying 
SOA  principles 

Service  Oriented  Architecture  (SOA)  is  a  set  of  design  principles,  whereas  cloud  is  a  service.  Cloud  based  services 
will  be  defined  and  enabled  through  SOA.  As  such  SOA  is  a  prerequisite  to  reap  cloud  computing  benefits.  However, 
following  SOA  design  principles  alone  does  not  guarantee  the  ability  to  easily  transition  to  a  cloud  based  solution 

...traditional 

hosting 

Cloud  and  traditional  hosting  share  many  characteristics  but  unlike  traditional  hosting  cloud  service  is  offered  on- 
demand,  is  scalable  and  elastic  -  a  user  can  have  as  much  or  as  little  of  the  service  as  they  need  and  pay  for  the 
resources  actually  used 

Cloud  computing  offers  increased  agility  through  faster  time  to  market,  lower  upfront  IT  capital  expenditure  and  the  ability  to 
easily  scale  up  /  down  and  reallocate  resources.  However,  technical,  operational  and  financial  hurdles  need  to  be  overcome 

before  cloud  can  be  used  extensively  by  large  enterprises 
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Cloud  services  offer  multi-tenant,  on-demand,  scalable,  elastic,  pay-as-you-go 
building  blocks  to  deploy  IT  solutions 


Cloud  Service  Types 


Hosted 

Applications 


Infrastructure 

Software 


Operating 

Systems 


Virtualization 


Servers 


Connectivity 


Data  Centre 


c/: 

re 

re 


Service  Type 

Definition 

Cloud  Candidates 

Sample  Vendors  j 

Software-as-a-Service 

(SaaS) 

Provider  licenses  an  application 
to  customers  for  use  as  a  service 
on  demand 

■  Non-core  applications  (e.g.,  HR,  CRM, 
and  document  collaboration) 

■  Email 

fr -  GMail 

mice 

ORACLjE'  ®,ght 

ON  DEMAND  NOW 

ssan 

ft 

Sr 

Platform-as-a-Service 

(PaaS) 

Building,  delivering  applications 
&  services  from  Web;  Computing 
platform  and  solution  stack  as  a 
service 

■  Large-volume  storage,  batch 
processing,  large-volume  computations 

■  VoIP,  Virtualized  Desktops,  Cloud 
Storage 

l  J  Windows  Azure 

vm/orce 

J&rcexonr 

pfarfwma'i  awwto* 

Jo. 

0SS8le 

Infrastructure-as-a- 
Service  (laaS) 


Computer  infrastructure  (typically 
a  platform  virtualization 
environment)  as  a  service 


Dev  and  Test  Environments 

High  compute  calculations  (e.g.,  Monte- 
Carlo  scenario  analysis) 

Web  servers 


St 

amazon  W 

web  services  "  terremark 
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rackspace 
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Cloud  Delivery  Models 

Delivery  Model 

Definition 

Public  Cloud 

■ 

■  External  to  a  client’s  premises 

■  Infrastructure  third-party  owned  and  managed 

■  Multi-tenant 

■ 

Subscription-based 

Scalable  and  elastic 

Metered  by  use 

Access  via  Internet 

■  External  to  a  client’s  premise  ■ 

Scalable  and  elastic 

Virtual  Private  Cloud 

■  Third-party  owned  and  managed 

Access  via  dedicated  but  private  link  to  public  cloud 

■  Multi-tenant  (but  virtually  private) 

Segmented,  secured,  or  compartmentalized  for  client 

Private  Cloud 

■ 

■  Usually  internal  and  delivered  on  client  premises  (although  can  be 
hosted  by  third-party  provider) 

■  Only  used  by  internal  customers 

Scalable  but  with  elasticity  constraints 

Access  via  private  link  or  internal 

Exclusive  membership 

Spectrum  of  control  /  ownership 

Community  Cloud 

■  As  per  private  cloud  but  shared  infrastructure  resources  with  “communities”  or  groups  with  similar  requirements  (e.g.,  industry  peers) 

Hybrid  Cloud 

■  Mix  of  private  and  public  cloud  environments  (e.g.,  data  stored  in  private  premises  but  other  infrastructure  shared  in  public  cloud) 
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Where  does  cloud  fit?  (Source:  David  Linthicum  c  2010) 


A  Fit  When: 

Processes,  applications,  and  data 
are  largely  independent 

Points  of  integration  are 
well  defined 

Lower  level  of  security  is  fine 

Core  internal  enterprise 
architecture  is  healthy 

Web  is  the 
desired  platform 

Cost  is  an  issue 

Applications  are  new 


Not  A  Fit  When: 

Processes,  applications,  and  data 
are  largely  coupled 

Points  of  integration  are 
not  well  defined 

Higher  level  of  security  is  required 

Core  internal  enterprise 
architecture  needs  work 

The  application  requires 
a  native  interface 

Cost  is  an  issue 

Application  is  legacy 
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Where  to  Begin 


Where  to  Begin?  Technology  Strategy 


1.  Begin  with  a  review  of  the  business  strategy,  realized  through  a 
business  operating  model 

2.  Define  the  business  drivers,  scope  and  key  stakeholders,  data, 
services  and  processes 

3.  Assess  the  current  state,  define  the  future  state,  and  create  a  transition 
plan  “roadmap” 

4.  Leverage  an  enterprise  architecture  methodology,  such  as  TOGAF 
and/or  DODAF,  to  build  integrated  artifacts 

5.  Extend  the  business  and  technology  analysis  to  define  parameters  and 
metrics  to  apply  to  all  technology  alternatives,  including  cloud 

6.  Incorporate  all  findings  to  prioritize  a  technology  migration  plan 


Deloitte. 


-9- 


Cascading  Effect 


Strategy  Relationships 


Business  Mission 
and  Vision 

l _ 


IT  Strategy 

l 


IT  Roadmap 
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Understanding  the  Relationships  (Source:  David  Linthicum  c  2010) 
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Simplified  View  of  Enterprise  Architecture 


Mission  &  Vision 

Business 


Technology 

Standards  and 
Reference  Models 


Current  State  Future  State 


•  Stakeholders 

•  Capabilities 

•  Services 

•  Processes 

•  Logical  Data 

•  Stakeholders 

•  Capabilities 

•  Services 

•  Processes 

•  Logical  Data 

•  System  Actors 

•  Existing  Systems 

•  Manual  Systems 

•  System  Functions 

•  Physical  Data 

•  Technology 
Options 

1. 

2. 

3. 

Environmental 

Changes 
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Business  Process  Integration 


Leverage  the  Business  Operating  Model  Classification 

Cited  from  “Enterprise  Architecture  as  Strategy”  c  2006  HBS  Press 


1  Coordination 

■  Organic:  stream  of  product  innovations 
easily  made  available  to  enisling 
customers  using  existing  integrated 
channels 

■  A  cqu initio n :  can  ac quire  new  customers 
for  existing  products  but  must  integrate 
data 

Unification 

*  Organic:  feverage  economies  of  scale  by 
introducing  existing  product/services  in 
new  markets:  grow  product  line 
incrementally 

■  Acquisition:  can  acquire  competitors  to 
leverage  existing  foundation:  must  rip 
and  replace  infrastructure 

Diversification 

■  Organic:  small  business  units  may  feed 
core  business:  company  grows  through 
business  unit  growth 

■  Acquisition:  unlimited  opportunities: 
must  ensure  shareholder  value 

1 - 

Replication 

■  Organic:  replicates  best  practices  in  new 
markets;  innovations  extended  globally 

m  Acquisition:  can  acquire  competitors  to 
expand  market  roach:  must  np  and 
replace 

Low - *  Hrgli 

Business  Process  Standardization 
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Scoping 


•  There  are  four  dimensions  in  which  scope  may 
be  defined  and  limited: 

-  Enterprise  scope  or  focus 
-Architecture  domains 
-Vertical  scope  (level  of  detail) 

-Time  periods  (project  schedule) 
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The  Open  Group  Architecture  Framework  (c  The  Open  Group) 


Preliminary 


ArcHi  pctum 
Vision- 


Architecture 

Change 

Management 


Business 

Architecture 


information 

Systems 

Architectures 


Requirements 

Management 


implementation 

Governance 


Technology 

Architecture 


Migration 

Planning 


Opportunities 

and 

Solutions 
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Phase  C:  Information  System  Architecture  (c  The  Open  Group) 


Defines  the  applications  and  data 
considerations  that  support  the 
enterprise's  Business  Architecture 

Primary  outputs  of  the  ISA  are 
Target  Architectures  covering  data 
and/or  application  system  domains 

Consider: 

•  Data  ->  Service  ->  Process  -> 
Platform 

•  Define  the  information  models 

•  Define  the  service  models 

•  Cloud  obscures  platform  details 


Deloitte. 


-  16  - 


Why  Information  System  Architecture  Matters  to  the  Business,  for  Cloud 


•  Data  Architecture  -  defines  the  major  types  and  sources  of  data 
necessary  to  support  the  business  in  a  way  that  is  understandable 
by  stakeholders,  complete  and  consistent,  and  stable 

-  Not  database  design,  it’s  about  defining  data  elements 
and  data  relationship  rules  relevant  to  the  enterprise. 


•  Application  Architecture  -  defines  the  major  kinds  of  application 
systems  necessary  to  process  data  and  support  the  business. 

-  Not  application  systems  design,  it’s  what  applications  are 
relevant  to  the  enterprise. 
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Artifacts  List  -  Data  Architecture 


•  Data  Entity/Data  Component  catalog 

•  Data  Entity/Business  Function  matrix 

•  System/Data  matrix 

•  Class  Diagram  or  Relational  Data  Model 

•  Data  Dissemination  diagram 

•  Data  Security  diagram 

•  Class  Hierarchy  diagram 

•  Data  Migration  diagram 

•  Data  Lifecycle  diagram 
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Artifacts  List  -  Application  Architecture 


•  Interface  catalog 

•  System/Organization  matrix 

•  Role/System  matrix 

•  System/Function  matrix 

•  Application  Interaction  matrix 

•  Application  Communication  diagram 

•  Application  and  User  Location  diagram 

•  System  Use-Case  diagram 

•  Enterprise  Manageability  diagram 

•  Process/System  Realization  diagram 

•  Software  Engineering  diagram 

•  Application  Migration  diagram 

•  Software  Distribution  diagram 
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The  DoD  Architecture  Framework  (DoDAF)  Viewpoints 
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Capability  Viewpoint 
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^.r  ElOtiLtl-H?  9pnraii«iwil  swftiuce.iiioctf&fcoy.  mi iv Jifa* 

4  fpqurejnervs 


Se  ni  Ices  V  tew  pol  rn 

Artie. j  late  file  performers,  aciiviiies,  services,  and 
th  p  ir  o  xehanigc  c  provklii  g  toi,  or  ti uppotUng,  DoD 

iundtorja 


Systems  Viewpoint 
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Operational  Viewpoint  (OV) 


•  Organizations  and  Performers  (actors/stakeholders) 

•  Tasks,  or  activities  performed  (processes) 

•  Information  that  must  be  exchanged  between  tasks/activities  for 
mission  accomplishment  (data) 

•  Types  of  information  exchanged 

•  Frequency  of  exchange 

•  Which  tasks  and  activities  are  supported  by  the  information 
exchanges,  and 

•  Nature  of  information  exchanges. 
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Operational  View  Models 


OV-1 :  High  Level  Operational 
Concept  Graphic 

The  high-level  graphical/textual  description  of  the  operational 
concept. 

OV-2:  Operational  Resource  Flow 
Description 

A  description  of  the  resource  flows  exchanged  between 
operational  activities. 

OV-3;  Operational  Resource  Flow 
Matrix 

A  description  of  the  resources  exchanged  and  the  relevant 
attributes  of  the  exchanges. 

OV-4:  Organizational  Relationships 
Chart 

The  organizational  context,  role  or  other  relationships  among 
organizations.  !. 

OV-5a:  Operational  Activity 
Decomposition  Tree 

The  capabilities  and  activities  (operational  activities)  organized  in 
an  hierarchal  structure.  , 

OV-5b.  Operational  Activity  Model 

The  context  of  capabilities  and  activities  (operational  activities) 
and  their  relationships  among  activities,  inputs,  and  outputs; 
Additional  data  can  show  cost,  performers  or  other  pertinent 
information. 

OV-6a:  Operational  Rules  Model 

One  of  three  models  used  to  describe  activity  (operational 
activity),  it  identifies  business  rules  that  constrain  operations. 

OV-6b:  State  Transition 

Description 

One  of  three  models  used  to  describe  operational  activity 
(activity).  It  identifies  business  process  (activity)  responses  to 
events  (usually,  very  short  activities). 

GV-6c:  Event-Trace  Description 

One  of  three  models  used  to  describe  operational  activity 
(activity).  It  traces  actions  in  a  scenario  or  sequence  of  events. 
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Services  Viewpoint  (SvcV) 


•  System  Functionality 

•  Service  Functionality 

•  Interconnection  between  Services 

•  Service  support  for  Operational  Activity 
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Services  Viewpoint  Models 


SvcV-1  Services  Context 

Description 

The  identification  of  services,  service  items,  and  their 
interconnections. 

SvcV-2  Services  Resource  Flow 
Description 

A  description  of  resource  flows  exchanged  between  services. 

SvcV-3a  Systems-Services  Matrix 

The  relationships  among  or  between  systems  and  services  in  a 
given  Architectural  Description. 

SvcV-3b  Services-Services  Matrix 

The  relationships  among  services  in  a  given  Architectural 
Description.  It  can  be  designed  to  show  relationships  of  interest. 
(e.g.r  service-type  interfaces,  planned  vs.  existing  interfaces). 

SvcV-4  Services  Functionality 
Description 

The  functions  performed  by  services  and  the  service  data  flows 
among  service  functions  (activities) 

SvcV-5  Operational  Activity  to 
Services  Traceability  Matrix 

A  mapping  of  services  (activities)  back  to  operational  activities 
(activities). 

SvcV-6  Services  Resource  Flow 
Matrix 

It  provides  details  of  service  resource  flow  elements  being 
exchanged  between  services  and  the  attributes  of  that  exchange. 

SvcV-7  Services  Measures  Matrix 

The  measures  (metrics)  of  Services  Model  elements  for  the 
appropriate  time  frame(s). 

SvcV-8  Services  Evolution 
Description 

The  planned  incremental  steps  toward  migrating  a  suite  of 
services  to  a  more  efficient  suite  or  toward  evolving  current 
services  to  a  future  implementation. 
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Services  Viewpoint  Models  (continued) 


SvcV-9  Services  Technology  & 

Skills  Forecast 

The  emerging  technologies,  software/hardware  products,  and 
skills  that  are  expected  to  be  available  in  a  given  set  of  time 
frames  and  that  will  affect  future  service  development. 

SvcV-1  Oa  Services  Rules  Model 

One  of  three  models  used  to  describe  service  functionality.  It 
identifies  constraints  that  are  imposed  on  systems  functionality 

due  to  some  aspect  of  system  design  or  implementation. 

SvcV-1  Ob  Services  State 

Transition  Description 

One  of  three  models  used  to  describe  service  functionality.  It 
identifies  responses  of  services  to  events. 

SvcV-1  Oc  Services  Event-Trace 
Description 

One  of  three  models  used  to  describe  service  functionality.  It 
identifies  service-specific  refinements  of  critical  sequences  of 
events  described  in  the  Operational  Viewpoint. 
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Integrating  Artifacts 


•  Data  and  Applications  artifacts  should  have  the  same  scope  to  support 
the  analysis  and  documentation 

•  Cross-referencing  the  artifact  components  in  a  matrix  can  identify 
where  and  how  specific  data  objects  support  specific  application 
functions 

•  Repository-based  EA  tools  can  store  data  objects  for  use  in 
associating  with  processes  when  building  process  models 

•  Associations  between  logical  data  and  logical  business  processes  are 
frequently  stable  over  time 
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Leverage  Artifacts  to  Populate  the  Enterprise  Architecture 


1 .  Artifacts  range  from  catalogs,  to  matrices  to  diagrams  to  models 

2.  Sample  business  artifacts  include  stakeholder  interaction  diagrams, 
process  models  and  data  models 

3.  Sample  technology  artifacts  include  system  catalogs,  physical  data 
models 

4.  Sample  transition  artifacts  include  consolidated  gaps,  solutions  and 
dependencies  assessment  matrix,  architecture  definition  increments 
table,  business/benefit  value  assessment  matrix 

5.  Define  services  at  the  macro  and  micro  business  and  technology 
levels,  and  define  parameters  (as  if  to  outsource) 
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Example:  Logical  Data  Model  and  Business  Object  CRUD  Matrix 


■  Integration  and  optimization  of  business  processes  and 
systems  functions  requires  understanding  the  data 
elements  supporting  the  activities 

■  Data  Models  are  the  most  stable  products  in 
architectures.  Data  entities,  attributes,  and  their 
relationships  reflect,  analyze  and  enforce  business  rules 
in  the  most  logically  consistent  way 

■  Conceptual,  Logical  and  Physical  Data  Models  are 
leveraged  across  multiple  layers  of  the  architecture 
framework 

■  Including  data  sets  in  system  artifacts  adds  valuable 
detail  and  strengthens  links  across  business,  solution  and 
systems  architectures 


In  the  diagrams  to  the  right: 

■  The  data  model  excerpt  identifies  data  entities,  attributes 
and  relationships,  and 

■  The  Business  Object  CRUD  Matrix  maps  primary 
functions  with  data  entities,  detailing  where  a  function 
“Creates”,  “Reads”,  “Updates”  and/or  “Deletes”  instances 
of  the  data.  This  is  a  critical  cross  reference  between 
data  and  functions. 


Order  Processing  System  CRUD  Diagram  2 
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laaS  cloud  suitable  applications  should  be  evaluated  based  on  the  degree  of 
technical  and  business  fit  against  key  cloud  characteristics 
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Common  initial  cloud  candidates  include  Analytics,  ECM,  and  BPM  tools 
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Simplified  View  of  Enterprise  Architecture 
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Simplified  View  of  Enterprise  Architecture 
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Analysis  of  Future  State 


Business  and 

IT  Strategy 
Alignment 

►  How  do  cloud  computing  technologies  and  services  align  with  business  and  IT  strategic  goals? 

►  What  business  benefits  can  be  derived  by  utilizing  cloud  computing  technologies,  and  to  what  degree? 

Opportunities 

►  How  can  you  determine  which,  if  any,  cloud  computing  technologies  and  services  are  suitable  for  the 
company? 

►  How  does  cloud  technology  differ  with  existing  service  types,  in  terms  of  functions  and  characteristics? 

►  How  can  cloud  technology  support  current  and  new  service  or  application  deployments? 

►  Which  cloud  computing  services  provide  the  highest  potential  business  value? 

►  How  much  flexibility  in  Capital  /  Operating  Expenditures  can  be  gained? 

Technologies  and 
Services 

►  Which  cloud  computing  technology  fit  your  current  or  planned  IT  infrastructure  and  architecture? 

►  Which  cloud  computing  vendors  fit  your  IT  and  business  needs? 

Delivery  Models 

►  To  what  degree  can  the  existing  delivery  methods  be  leveraged? 

►  Who  are  the  leading  cloud  computing  providers  for  each  service  type  and  technology? 

►  How  will  procuring  cloud  services  affect  relationships  with  existing  vendors? 

►  Are  the  standard  Service  Level  Agreements  acceptable  to  you? 

IT  Readiness 

►  What  business  and  IT  processes  are  affected  when  transitioning  to  cloud-based  capability? 

►  To  what  degree  can  existing  IT  infrastructure,  technologies,  and  services  be  leveraged? 

►  Does  the  organization  have  the  capabilities  to  make  adequate  use  of  cloud  computing  technology? 

►  Are  the  appropriate  security  and  privacy  controls  in  place  to  support  cloud  computing  technology? 

Roadmap 

►  What  are  the  immediate  next  steps? 

►  What  cloud  computing  initiatives  can  be  planned  to  take  place  in  the  next  2-3  years? 
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Additional  Considerations  for  Future  State  Technology 


Define  metrics  for  critical  business  performance  areas,  and  ensure  these 
are  inherited  by  system  alternatives 

Include  cloud  computing  options  as  part  of  the  future  state  technology 
alternatives  for  comparison 

Ensure  systems  principles  of  technology  architecture,  dependability,  and 
performance  metrics  are  maintained  through  all  alternatives,  which 
often  will  require  levels  of  diversification  and  redundancy  to  achieve 

Ensure  service  definition  and  metrics  are  derived  from  the  business 
operating  model 

Ensure  the  technology  alternatives  support  and  map  to  the  business 
drivers,  scope,  stakeholders  and  operating  model 
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Not  all  applications  are  suitable  for  cloud,  enterprises  should  consider  several 
dimensions  when  evaluating  which  future  applications  are  built  to  be  cloud-ready 


Considerations  For  Building  a  Cloud  Ready  Application 


Technology 


■  Do  the  workloads  exhibit  characteristics  that  can  derive  real  benefits 
from  scalability  and  elasticity? 

■  Will  the  application  be  built  to  run  on  a  cloud  supported  platform  (e.g., 
commodity  hardware,  supported  OS) 

■  Can  the  application  components  be  architecturally  designed  to  be 
suitable  for  deployment  to  a  cloud  based  solution? 

■  What  design  trade-offs  will  be  needed  to  make  this  application  cloud- 
ready? 

■  Are  internal  IT  architecture  and  organization  structures  “ready”? 


Business 


■  What  are  the  anticipated  usage  patterns  for  the  application  and  will  it  be 
cost  effective  to  move  to  the  cloud? 

■  What  is  business  sponsor's  preference  for  CapEx  vs  OpEx? 

■  How  will  designing  for  cloud  readiness  impact  my  implementation 

cost  and  timelines?  Can  I  achieve  overall  lower  TCO? 

■  Will  moving  to  cloud  help  me  capture  new  sources  of  value  for  the 

business? 

■  Are  cloud  offerings  mature  enough  for  these  workloads? 


Operational 


■  What  are  the  availability  requirements  for  this  application  and  can 
those  be  met  by  cloud? 

■  How  will  support  model  for  this  application  change  if  it  is  moved  to 
the  cloud?  Are  the  potential  changes  acceptable? 

■  How  will  cloud  impact  my  chargeback  model  for  this  application?  Can 
I  support  the  new  model?  Will  business  accept  the  changes? 

■  Can  cloud  meet  my  business  continuity  and  disaster  recovery 
requirements  for  the  application? 

■  Is  the  vendor  limiting  interoperability  or  access  to  your  data? 


Regulatory  and  Compliance 


■  Are  there  any  risk  management  or  compliance  requirements  for  this 
application?  Will  cloud  be  able  to  satisfy  those  requirements?  (e.g., 
Audits) 

■  Does  the  application  hold  confidential  or  customer  data?  Can  this  data 
be  easily  masked  in  the  future? 

■  Does  the  application  data  need  to  reside  within  organization?  Will  we  be 

prohibited  from  moving  data  outside  of  the  country? 

■  Who  owns  the  data?  How  is  it  be  used?  Are  controls  in  place? 

■  How  is  security  achieved?  What  is  the  level  of  privacy  protection? 

■  Can  you  meet  needs  for  legal  compliance  and  tax  issues? 
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Applications  most  suited  to  cloud  computing  have  dynamic  and  unpredictable  usage 
patterns,  compared  to  more  static  hosting  environments 


Comparing  Managed  Hosting  to  Cloud  Computing 


Managed 

Hosting 

Applications 

■  Email  &  Messaging  ■  Legacy  Applications 

■  Voice  Systems  ■  Structured  Databases 

■  Corporate  Web  Sites  ■  Financial  Systems 

■  Back-Office  Systems 

“Static  & 
Continuous” 

Cloud 

Applications 

■  Software  as  a  Service  ■  Collaboration  &  Analytics 

■  Dynamic  Applications  ■  Test  and  Development 

■  High-Compute  Processing  ■  DR,  Backup  and  Storage 

“Dynamic  & 
Bursty” 

Mainstream  Adoption  of  Workloads  by  Service  Type 


Service  type  solution  maturity  over  the  next  4  years  and  expected  timeframe  for  mainstream  adoption  of  workload  types 
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Outputs  I  Analysis  I  Inputs  I  Source 


Cloud  Suitability  Evaluation  Criteria 


A  structured  approach  should  be  taken  when  reviewing  laaS  cloud  suitability  factors 
for  applications  and  workloads 


Level  1 

Workload  Analysis 


Suitability  Assessment 


Level  2 

Determine  Suitability  for  Cloud 
(laaS  Cloud  Candidates) 


In  Depth  Analysis  &  Planning 

a 


Level  3 

Business  Case  and 
Operational  Analysis 


Execution 


Workload  attributes 
Application  characteristics 
Suitability  framework 


Technical  reviews  with  application  owners  and  infrastructure  teams 
Input  from  application  business  owners  and  SLAs 


TCO  Data  and  Analysis 
Stakeholder  Inputs 


Business  Case  Analysis 
Technical  Analysis 


Workload  Attributes 


Potential  Cloud 
Candidates 


Feasible  Cloud 
Candidates 


Proposed  Cloud 
Candidates 


Applications  /  Workloads 
Targeted  for  Migration 


Preliminary  Assessment 

■  Application  Criticality 
(business  criticality  of  app) 

■  Application  Complexity 

■  Poor  Virtualization 
Candidate 

■  Utilizes  Commodity 
Infrastructure 


Technical  Feasibility 

■  High  Network  Bandwidth  Needs 

■  Infrastructure  Requirements 

■  Shares  Environments 

■  Shares  Software  Stack 

■  Utilizes  Specialized 
Infrastructure 


Business  Feasibility 

■  Internal  /  External  Facing 
Application 

■  High  User  Impact 

■  Service  Level  Requirements 

■  Confidential  /  Customer  Data 


Detailed  Analysis 

■  Business  Case  Analysis 

■  Detailed  Technical  Analysis 

■  Operational  Analysis 

■  Management  Considerations 


Migration  Planning 
Testing 

Change  Management 
Cutover 


In-house  /  Co- 
location 
Candidates 


Not  Technically 
|  Feasible 


Not  Business 
|  Suitable 


Migration  Not 
Feasible 


Evaluate  Suitability  for  SaaS  and  PaaS 


Candidate  list  for  cloud 
evaluation 


List  of  cloud  applications  /  workloads  with  high  migration  potential 


Business  Case  Analysis 
(including  cost  vs.  run  rate 
analysis) 

Technical  Analysis 


Detailed  application  and 
workload  migration 
analysis 

Migration  plan 
Realized  benefits 


Filtered  App  /  Workload  O  Identified  App  /  Workload 
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Organizations  face  a  wide  range  of  new  risk  and  control  considerations  when 
transitioning  to  the  cloud 


■  Amongst  the  many  operational  impacts  cloud  brings,  it  introduces  new  inherent  risks  and  increases  the  complexity  of  managing  existing  risks 
that  may  be  well  controlled  in  the  internal  environment;  primarily  around  data  security. 

■  For  instance,  a  non-US  company  may  face  the  challenge  of  a  vendor  only  providing  data  centres  in  the  US  which  would  make  data  subject  to  the 
Patriot  Act. 

-  Risk  and  Control  Considerations  - 


Who  will  own  the  data?  How 
might  it  be  used? 


Do  the  cloud  vendor’s 
retention/destruction  timelines  and 
practices  meet  your  requirements? 


Data  Controls  and  Ownership 


Where  will  your  data  reside? 
Who  can  access  your  data? 


Data  Location  and  Access 


Can  cloud  vendors  comply  with 
your  regulatory  /  compliance 
requirements? 


Legal  /  Regulatory  Compliance 


Backup,  Retention,  Disposal 


How  is  reliability,  access,  and 
availability  assured  by  cloud 
vendors? 


Availability  and  Reliability 


What  are  operational  continuity 
measures  and  recovery  timelines? 


Disaster  Recovery 
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Transition  Planning:  Leveraging  TOGAF  Phases  E,  F,  G  &H: 


Ptalmi:  1 

'famflwofk  and 
Principles  J 
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Change 
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Business 
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information 

System 
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Requirements 


NrrfrtemefiiatiOfi 
i  governance  1 


Miration 

Planning 


Technology 

ArcNteotune 


Opptoftunlues 
tand  Solutions . 


Opportunities  and  Solutions: 

Identifies  changes  and  projects  to  be  undertaken  to  move 
from  current  to  target  state. 

Migration  Planning: 

Focuses  on  prioritization  of  projects.  Generates  detailed 
implementation  roadmap,  timeline  as  well  as  the  impact 
analysis. 

Implementation  Governance: 

Defines  implementation  contract  which  guides  and 
governs  the  projects. 

Architecture  Change  Management: 

Helps  to  manage  changes  in  a  cohesive  way. 


-42  - 


Deloitte. 


Transition  Planning 


The  most  critical  aspect  of  transition  planning:  the  evolution  of  the 
business  operating  model 

Leverage  the  gap  analysis  between  current  state  business  and  future 
state  business,  between  current  state  business  and  current  state 
technology,  and  between  current  state  environmental  factors  and 
future  state  projected  environmental  conditions 

Ensure  performance  metrics  are  defined  and  baselined  for  realistic 
comparison  of  alternatives  and  for  prioritization  of  migration  options 
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Transition  Planning  Includes  Data  Security 


Example  of  Systems  Security  Concerns,  cited  from  the  US  Federal  Cloud  Computing 
Strategy 

(Detailed  cloud  security  guidance  is  available  through  a  series  of  NIST  publications.  NIST  has  also  classified  cloud  service 
models  and  cloud  deployment  models.) 

1.  Statutory  compliance  to  laws,  regulations,  and  agency  requirements 

2.  Data  characteristics  to  assess  which  fundamental  protections  an  application’s  data  set 
requires 

3.  Privacy  and  confidentiality  to  protect  against  accidental  and  nefarious  access  to 
information 

4.  Integrity  to  ensure  data  is  authorized,  complete,  and  accurate 

5.  Data  controls  and  access  policies  to  determine  where  data  can  be  stored  and  who  can 
access  physical  locations 

6.  Governance  to  ensure  that  cloud  computing  service  providers  are  sufficiently 
transparent,  have  adequate  security  and  management  controls,  and  provide  the 
information  necessary  for  the  agency  to  appropriately  and  independently  assess  and 
monitor  the  efficacy  of  those  controls 


Deloitte. 


-44- 


Deloitte 


Conclusion 


-45  - 


Conclusion 


1.  Cloud  Computing  is  a  great  way  to  avoid  the  cost  of  implementing  and  managing 
infrastructure;  what  you  run  on  that  infrastructure  and  how  successful  the  results  will  be 
depends  on  the  skill  and  effort  your  team  put  into  the  work. 

2.  However:  Cloud  computing  requires  architecture,  management  and  implementation. 

Start  with  architecture. 

3.  Most  critical  aspect  of  architecture  analysis:  the  business  operating  model. 

4.  Establish  current  state,  future  state  and  transition  plans 

5.  Define  metrics  for  critical  business  performance  areas,  and  ensure  these  are  inherited  by 
systems  (SLAs) 

6.  Include  cloud  computing  options  as  part  of  the  future  state  technology  alternatives  for 
comparison 

7.  Ensure  systems  principles  of  technology  architecture,  dependability,  and  performance 
metrics  are  maintained  through  all  alternatives,  which  often  will  require  levels  of 
diversification  and  redundancy  to  achieve 
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Given  the  significant  benefits  that  cloud  offers,  mainstream  adoption  likely  as  vendor 
solutions  mature  and  operating  model  challenges  are  overcome 


-  Finding  Value  Beyond  The  Hype  - 

■  The  hype  cycle  for  cloud  is  at  all-time  high  and  for  good  reason  -  the  benefits  companies  stand  to  gain  from  cloud  are  significant:  IT 
agility,  decreased  costs  and  improved  IT  service  delivery  capabilities  to  name  but  a  few 

■  The  big  question  is  how  -  not  if.  Take-up  statistics  show  that  a  large  proportion  of  enterprises  are  beginning  to  leverage  cloud  to  some 
extent  or  the  other.  Wider  scale  adoption  is  primarily  being  held  back  due  to  organizations  trying  to  understand  how  to  overcome 
challenges  such  as  adopting  new  operating  models,  shaping  appropriate  data  governance  policies,  addressing  new  security  and  risk  controls, 
and  understanding  how  to  adjust  tax  strategies  to  the  cross-border  intricacies  that  cloud  can  bring 


-  Long  Term  Outlook  - 

■  The  consensus  on  cloud  growth  remains  polarized:  One  positions  cloud  at  the  apex  of  the  hype  curve,  but  still  two  to  five  years  away  from 
mainstream  adoption.  The  other  suggests  that  cloud  is  about  to  “explode”  over  the  next  year 

■  In  reality,  in  the  immediate  term  we  are  likely  to  see  growth  in  segments  where  offering  dynamically  scalable  and  virtualized  resources 
makes  good  business  sense  (e.g.,  non-critical  file  storage  or  customer-facing  applications  that  see  large  spikes  in  demand) 


■  The  strong  benefits  that  cloud  offers  and  the  improved  solution 
maturity  and  diversity  from  vendors  indicate  that  it  is  here  to  stay 

■  Moreover,  many  of  the  operational  and  security  challenges  can 
be  addressed  through  vendor  management  and  enterprise 
architecture  standardization 

■  Within  the  five  year  time  horizon,  it  is  expected  that  core  cloud 
solutions  will  become  mainstream  services  adopted  widely  by 
enterprise  customers 

■  Bottom  line:  Enterprises  should  take  the  steps  now  to  ensure 
they  are  well  positioned  to  leverage  cloud  benefits  in  the 
future;  this  includes  ensuring  that  there  is  a  cloud  strategy  in 
place,  that  architecture  is  being  built  “cloud-ready”,  and  that 
consideration  has  been  given  to  future  operating  model 
implications 


■  SaaS  "PaaS  "laaS 

Gartner  Cloud  Market  Growth  Forecasts  for  SaaS,  PaaS  and  laaS 


Sources:  Deloitte  -  Cloud  Computing:  Finding  Value  Beyond  The  Hype;  Deloitte  -  TMT  Predictions  201 0;  Gartner  -  Hype  Cycle  for  Cloud  Computing  201 0;  Gartner  -  The  Cloud-Computing  Scenario  201 0 
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